In recent years, multi vendors interlink and integrate different work systems and open information between different systems to exchange information. As a result, an IT system has become larger and more complex concomitantly with an increase in number of servers or an increase in capacity of storages. Therefore, problems may arise in that operation cost increases and the system stops or service quality deteriorates due to human error. In order to solve these problems, the management of information regarding the IT system configuration such as the servers, storages, and applications becomes important.
For example, operation management middleware optimized for management work such as server management, network management, service management, and asset management are necessary for an operation of a data center. Each operation management middleware includes unique database and registers configuration information regarding each work in a database. Thus, in order for the operation management middlewares to independently manage the configuration information from other databases, work for interlinking the operation management middlewares has to be carried out in practice by a human source since access methods or schemas of the configuration information are different between the operation management middlewares.
Accordingly, there is known a configuration information management including a database called a federated configuration management database (FCMDB) that virtually federates various kinds of configuration information scattered in a plurality of operation management middlewares. The FCMDB virtually federates the configuration information of the respective operation management middlewares. The operation management middleware federated by the FCMDB is called a management data repository (MDR). FIG. 16 is an explanatory diagram illustrating the structure of an FCMDB system. An FCMDB system 300 illustrated in FIG. 16 includes a plurality of MDRs 301, an FCMDB 302, and a client terminal 304. The MDRs 301 and the FCMDB 302 are connected to each other for communication via a network 303.
Each MDR 301 manages attribute items regarding configuration items such as apparatuses present in an IT system for each type of configuration items. Moreover, each MDR 301 manages not only types of configuration items of data for management and different amounts of data but also various kinds of information regarding the attribute item in association with the local ID of the own MDR. For example, an MDR 301A manages design information, an MDR 301B manages product information, an MDR 301C manages performance information, and an MDR 301D manages configuration information.
The FCMDB 302 federally manages the same target configuration information distributed and managed in the plurality of MDRs 301. Specifically, the FCMDB 302 manages configuration items (CIs) such as apparatuses, software, and data log forming an IT system. For example, the CI “C” managed by the FCMDB 302 is a federation of the configuration information of design information C″ managed by the MDR 301A, the performance information C^ managed by the MDR 301C, and the configuration information C′ managed by the MDR 301D.
As a consequence, an operator such as a person in charge of system management can manage and understand the configuration of the entire IT system with reference to the virtually federated configuration information using the FCMDB 302 under various situations associated with system operations such as deployment application work or hardware maintenance.
FIG. 17 is an explanatory diagram illustrating the principle of data federation of the FCMDB system 300. In the example of FIG. 17, the MDR 301A manages “server”, “ID: WebServer1”, and “S/N: XYZ123” as the attribute item of the same CI. The attribute item has an attribute name and an attribute value. The attribute name corresponds to, for example, “ID” and “S/N”. The attribute value corresponds to, for example, “WebServer1” and “XYZ123”. Moreover, the MDR 301B manages “ID: 192.168.0.1” and “PRODUCT NUMBER: XYZ123” as the attribute item of the same CI. The attribute name corresponds to, for example, “ID” and “PRODUCT NUMBER”. The attribute value corresponds to, for example, “192.168.0.1” and “XYZ123”. Moreover, the MDR 301C manages “HOST”, “ID: hostnameX”, and “SERNO: XYZ123” as the attribute item of the same CI. The attribute name corresponds to, for example, “ID” and “SERNO”. The attribute value corresponds to, for example, “hostnameX” and “XYZ123”. Moreover, the MDR 301D manages “NODE”, “ID: 192.168.0.1” and “SN: XYZ123” as the attribute item of the same CI. The attribute name corresponds to, for example, “ID” and “SN”. The attribute value corresponds to, for example, “192.168.0.1” and “XYZ123”. That is, the MDRs 301 each manage different CI types, although the CI types are the attribute items of the same CI.
The FCMDB 302 converts the attribute items of the same CI managed by the respective MDRs 301 into a common format. Moreover, the FCMDB 302 uses a common property, which has a unique attribute value different from the attribute items managed with the different local ID of each MDR 301, as a key and performs a reconciliation process to certify the attribute items of the same CI. The common property corresponds to the unique attribute value “XYZ123” such as “S/N: XYZ123”, “PRODUCT NUMBER: XYZ123”, “SERNO: XYZ123”, and “SN: XYZ123” indicating the product number.
The FCMDB 302 certifies the attribute items of the same CI using the common property of the product number from the plurality of attribute items managed with the different local ID of each MDR 301 as the key, and federally manages the attribute items of the same CI distributed and managed by the respective MDRs 301.
When the information regarding the plurality of schemas such as an a-XML format and a b-XML format is federally managed even in the same CI, the information regarding the schemas, for example, dictionary information such as the common property matching the attribute items has to be generated in order to perform the reconciliation process.
Examples of the related art include Japanese Laid-open Patent Publication No. 2007-179146, Japanese Laid-open Patent Publication No. 2006-99236. Further example of the related art includes “CMDB Federation (CMDBf)” Committee Draft Version 1.0 [online], Oct. 22, 2007, CMDB Federation Working Group [search in Jan. 23, 2008], Internet <URL: http://cmdbf.org/schema/1-0-0/CMDBf % 20 v1.0.pdf>.
In the method of generating the dictionary information according to the related art, however, it is necessary for an operator to search for information regarding the synonymous attribute items manually and to generate the dictionary information defining the synonymity between the attribute items of the plurality of schemas. As a consequence, in the method according to the related art, the work burden on the operator is considerably large when the dictionary information of the attribute elements of the plurality of schemas is generated.